1. Field of the Invention
The invention relates to network management, and specifically, to automatic configuration of a System Management Station and a managed object.
2. Description of the Prior Art
The purpose of monitoring a network is to manage network performance, discover and solve network problems, and plan for network growth. According to Morris Sloman (Editor), “Network and Distributed Systems Management”, Addison-Wesley, England, 1994, pg. 303, monitoring can be defined as the process of dynamic collection, interpretation, and presenting of information concerning objects or software processes under scrutiny. Monitoring can be used for general network management, such as performance management, configuration management, fault management, or security management. One important application of monitoring is event reporting which is explained below using definitions taken from the aforementioned text at pp. 303 to 347.
The network to be monitored is comprised of one or more managed objects. A managed object is defined as any hardware or software component whose behavior can be monitored or controlled by a management system. Hardware components may be hubs, routers, computers, bridges, etc. Each managed object is associated with a status and a set of events. The status of a managed object is a measure of its behavior at a discrete point in time. An event is defined as an atomic entity which reflects a change in the status of the managed object. The behavior of the managed object can be defined and observed in terms of its status and events.
The status of the managed object lasts for a certain time period. Examples of a status are “process is idle” or “process is running”. An event occurs instantaneously. Examples of an event are “message sent” or “process started”. Since the status of an managed object is normally changing continuously, the behavior of the managed object is usually observed in terms of a distinguished subset of events, called events of interest. Events of interest reflect significant changes in the status of the managed object.
In order to monitor the events of interest, events of interest must be detected. An event is said to have occurred when the conditions which are defined by event detection criteria are satisfied. These conditions are detected by appropriate instrumentation, such as software and hardware probes or sensors inserted in the managed object.
Event detection may be internal within or external from the managed object. Internally performed event detection is typically performed as a function of the managed object itself. Externally performed event detection may be carried out by an external agent which receives status reports of the managed object and detects changes in the status of the managed object.
The occurrence of the event may be detected in real-time or delayed. Once the event is detected, an event report is generated at the managed object. The event report may comprise an event identifier, type, priority, time of occurrence, the status of the managed object immediately before and after the occurrence of the event, and other application-specific status variables.
In order to monitor the dynamic behavior of the managed object, the event report may be conveyed from the managed object to a central unit. At the central unit event reports may be gathered, visualized, and recorded. The central unit may be a System Management Station (SMS) on which an appropriate software, usually called a manager, resides. The manager executes management applications that monitor and control the managed objects. Physically, an SMS, sometimes called a console, is usually an engineering workstation with a fast CPU, megapixel color display, substantial memory, and abundant disk space. The SMS may comprise a database on which incoming reports sent by the managed objects, such as event reports, are stored.
Received reports can be viewed with the Graphical User Interface (GUI) of the SMS.
In order to carry out network management, each managed object must not only know its event detection criteria, but the SMS must also know which devices of the network it shall monitors. Specifically, the SMS must know which of the devices are managed objects. If a device is added to the network and this device is to be monitored by the SMS, the device must be configured with its relevant event detection criteria and must be introduced to the SMS, so that the SMS will be able to communicate with it.
Described below is the way to appropriately configure an SMS and a device that has just been connected to a network according to the state of the art.
FIG. 1 depicts a network 100 having several managed objects 2 to 9. Managed objects 2 and 4 are computer controlled x-ray apparatuses, corresponding to a first type of managed object which is referred to as “x-ray apparatus”. Managed objects 3 and 5 are computer controlled magnetic resonance apparatuses corresponding to a second type of managed object which is referred to as “MR-apparatus”. Managed objects 6 and 7 are computed tomography apparatuses corresponding to a third type of managed object which is referred to as “CT-apparatus”. Managed objects 8 and 9 are standard PCs connected to the network 100, corresponding to a fourth type of managed object which is referred to as “PC”.
The network 100 is monitored with a System Management Station (SMS) 1 which physically is a computer connected to the network 100 using the agent-manager network management system HP OpenView. On the SMS 1 resides a manager which communicates with agents residing on the managed objects 2 to 9. The manager is software configured to receive reports sent by the agents. An agent is software configured to control and detect significant changes in the status of its corresponding managed object according to a predefined set of event detection criteria. In the present exemplary embodiment, agents of the same type of managed object are configured with essentially the same set of event detection criteria specific to that type of managed object. Therefore the agents of the managed objects 2 and 4, which are of the type “x-ray apparatus”, are configured with a set of event detection criteria specific to x-ray apparatuses; the agents of managed objects 3 and 5, which are of the type “MR-apparatus”, are configured with a set of event detection criteria specific to magnetic resonance apparatuses; the agents of managed objects 6 and 7, which are of the type “CT-apparatus”, are configured with a set of event detection criteria specific to computed tomography apparatuses, and managed objects 8 and 9, which are of the type “PC”, are configured with a set of event detection criteria specific to PCs connected to the network 100.
An operator (not shown in the Figures) monitors the network 100 with the SMS 1 by viewing a display of the network 100 on the screen of the SMS 1. The displayed network is depicted in FIG. 2. The managed objects 2 to 9 are represented as icons 22 to 29. Icons 22 and 24 represent the managed objects 2 and 4 (computer controlled x-ray apparatuses); icons 23 and 25 represent the managed objects 3 and 5 (computer controlled magnetic resonance apparatuses); icons 26 and 27 represent the managed objects 6 and 7 (computed tomography apparatuses); icons 28 and 29 represent the managed objects 8 and 9 (PCs).
When a new device is connected to the network 100, for example by a technician (not shown in the Figures), and the device is to be additionally monitored with the SMS 1, then not only must this new device be configured with its relevant set of event detection criteria, but also the SMS 1 must be reconfigured.
FIG. 3 shows the network 100 to which a new device, which is computed tomography apparatus 10, has just been connected. The network 100 including the computed tomography apparatus 10 has the reference sign 100′. According to the state of the art, the operator must manually configure the SMS 1, so that it monitors the computed tomography apparatus 10 by opening a window 40 with the SMS 1 and viewing it on the screen of the SMS 1. Window 40 is shown in FIG. 4.
Window 40 has several fields 41 to 44. The operator must indicate the IP-address of the computed tomography apparatus 10 in field 43, the name of the computed tomography apparatus 10 in field 42, and the operating system of the computed controlled computed tomography apparatus 10 in field 44. Field 41 of window 40 is meant for labeling an icon which will be generated and displayed on the screen of the SMS 1 after the computed tomography apparatus 10 has been registered. In this case, this icon will be labeled “CT apparatus 10”.
After the operator has appropriately filled out window 40, the SMS 1 is configured and an icon 30 representing the computed tomography apparatus 10 appears on the screen of the SMS 1 in addition to icons 22 to 29. This is illustrated in FIG. 5.
After configuring the SMS 1, the operator must configure the computed tomography apparatus 10 from the SMS 1 with its relevant event detection criterion or event detection criteria. The event detection criteria for a specific managed object can be defined using one or more appropriate templates. The template or templates may be stored on database 1a of the SMS 1. Once this template or templates are created, the relevant managed object, or more specifically its agent, will be configured with that template.
FIGS. 6 to 8 show an example of such a template 61. Template 61 defines an event detection criterion for monitoring the logfile of a managed object. Template 61 has a name-field 62 for defining template 61. In this case, the name of template 61 is “R0_HS_MST_VB22F_Syslog”. Additionally, template 61 has a description-field 63, in which a short description of the event detection criteria may be written. Template 61 has also a field 64 which specifies the path and the name of the file to be monitored. The name of the logfile is “syslog”. Furthermore, the time period in which the logfile “syslog” is automatically checked by the managed object for a new entry is defined by field 65 of template 61. In this example, the logfile “syslog” is checked each minute.
The actual event detection criteria of the managed object are defined utilizing a list 70, which is shown in FIG. 7. For this example, list 70 contains only one event detection criterion, which is: “Refused connect from denied node”.
FIG. 8 shows a list 80 which is used to define the message of an event report sent from the managed object to the SMS 1 if an event defined by the event detection criterion occurs. The message can be written in message text field 81. For this example, the message of the event report is “Connection refused from <*.node>”, when there is an unauthorized attempt to log on the managed object. “<*.node>” is actually a wildcard, which is replaced by the actual system's name from which the unauthorized log on was attempted.
Apparently, the operator of the SMS 1 must perform relatively many time consuming manual steps to configure the SMS 1 and the computed tomography apparatus 10.